System for storing and retrieving data

ABSTRACT

In one aspect, a method of storing data includes receiving instances of data and storing the instances in an entity instance table, allocating a unique identifier to each instance of data received for storage in the entity instance table, such that each instance can be uniquely referred to, and providing a relationship definition table for storing relationship definitions. Each relationship definition has three data fields. The method also includes receiving three unique identifiers of selected instances of data stored in the entity instance table and storing the three unique identifiers as a relationship definition in the relationship definition table. A relationship is defined by the unique identifiers of exactly three instances of data and each of the three unique identifiers is contained in a respective one of the three data fields of the relationship definition.

BACKGROUND OF THE INVENTION

This invention relates to a system for storing and retrievinginformation or data.

Databases are known systems for storing information and data. Data isstored in a number of distinct internal partitions known as tables whichcomprise one or more fields and records. A field, which is a column ofthe table, is defined by a space in memory used to hold one or more datavalues of a predetermined type. It is assumed that the data values atthe same or at a corresponding position across different fields, andwhich therefore form a single row of the table, are related. A row ofdata values is called a record.

For example, a column of numbers, regardless of any heading the columnhas, such as telephone numbers, when taken by itself offers littleinformation to a user. It is only by providing a second column of data,such as names which correspond to the numbers, that the numbers take ona meaning. The relationship between data values in tables is thereforemade implicitly by association.

Tables provide a simple and elegant way of storing and ordering data.However, in order to create a table in memory, the designer of a tablemust know in advance what type of data the table will store so thatsufficient and appropriate fields can be allocated and named. Thecreation of a table thus requires considerable forward thinking andplanning to ensure that the data is correctly and sensibly ordered.Although in some databases, existing tables can be expanded by theaddition of new fields, it is still necessary to know, before a field isadded, the intended nature of data it will hold so that it can beproperly defined.

The necessity of having to name every field and define the type of datait holds in advance is not only a burden for the designer of a table, itis also a burden for the user who wishes to add data values to the tableor extract data from it. Often in a database there will be a largenumber of tables, connected together in some way, so that the records orfield in one table relate to those in another. Thus, in order to accessthe data in a database, the user needs to know the table in which thedesired data is stored, and the field in which the desired data isstored. This can make data difficult to retrieve for users who are notfamiliar with the contents of a particular table or who have a largenumber of tables or databases to search through.

One known system which does not require the intended type of data thatis to be stored to be formally declared in advance is the NeuralNetwork. Such networks are trained with a large amount of input datauntil the desired output response is learned. Once a network is trained,a user may present an input to it and receive an output which isdependent on the training but which may be unpredictable at the time ofinput. There is however no indication of why the input produces aparticular output, and the user will have to infer the relationshiphimself.

A prior art system known as the Datalayer, described in InternationalPatent No. WO 00/14654 disposes with the need for a designer to specifyfields and tables in advance, by allowing fields to be allocated to dataat the time it is input. The relationship between the fields that areused must be declared when the data is input in order to preserve therelationship between the contents of the different fields.

We have appreciated that it would be desirable to provide a structurefor the storage and retrieval of data which require no prior knowledgeof what data is held on the part of either the creator of the datastructure or on the part of the user.

SUMMARY OF THE INVENTION

The scope of the invention is defined by the independent claims to whichreference should now be made. Advantageous features of the invention areset forth in the appendant claims.

The invention relates to a system for storing and retrieving informationthat allows data to be entered in a flexible and unrestricted way. Auser of the system enters instances of data as single elements known asEntities. A declaration of some arbitrary information may then be madeby specifying that three instances of data held as Entities are related.This is done using a construction called an Attribute. Each Entity has aunique identifier so that Entities which hold identical values may bedistinguished from each other, allowing distinct and independentdeclarations of information to be built up. The nature of thedeclaration and the way in which it is defined is left to the personinputting the data to specify or to leave as unspecified.

Attributes also receive a unique identifier and may therefore bereferred to by other Attributes in a declaration of information. Thuscomplex declarations may be made.

The stored set of Entities and Attributes may be searched for those thatmatch a given search term, and an output obtained. Furthermore, theresults of two or more searches may be processed, in dependence on acondition input by a user, to output a multitude of related data.

In one aspect, the subject matter defined herein corresponds to acomputer program product comprising a recording medium which is readableby a computer and having program code stored thereon from execution on acomputer. The program code defines an entity instance table into whichinstances of data can be entered for storage, wherein each instance ofdata that is entered is allocated a unique identifier such that eachinstance can be uniquely referred to. The computer program productfurther defines a relationship definition table for storing a pluralityof relationship definitions, each relationship definition having threedata fields, each data field containing the unique identifier of aselected instance of data stored in said entity instance table, wherebysaid relationship definition represents a relationship between saidselected instances of data.

BRIEF DESCRIPTION OF THE DRAWINGS

A preferred embodiment of the invention will now be described in moredetail and with reference to the drawings in which:

FIG. 1 illustrates the Repository employed by the preferred system tostore data;

FIG. 2 illustrates an example record set according to the preferredsystem;

FIG. 3 a schematically illustrates a first simple query of the recordset of FIG. 2;

FIG. 3 b schematically illustrates a second simple query of the recordset of FIG. 2;

FIG. 3 c illustrates an implicit relationship between the results shownin FIGS. 3 a and 3 b;

FIG. 4 a schematically illustrates a query of the record set of FIG. 2specifying a condition shown as X;

FIG. 4 b shows how the query illustrated in FIG. 4 a is processed;

FIGS. 4 c, 4 d and 4 e show the results of the query in various outputformats;

FIG. 5 illustrates a second record set;

FIG. 6 a shows a query of the record set illustrated in FIG. 5;

FIG. 6 b shows the results of the query illustrated in FIG. 6 a;

FIG. 6 c illustrates a single record output in the query.

FIG. 7 a shows a query of the record set illustrated in FIG. 5;

FIG. 7 b shows the results of the query illustrated in FIG. 7 a;

FIG. 7 c illustrates a single record output in the query; and

FIG. 8 illustrates a further example record set.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The preferred embodiment of the invention, provides a system for storingand retrieving data that does not require tables or fields to beexplicitly pre-defined in terms of the data or information that theywill hold. Instead a table capable of holding a multitude of data valuesand capable of describing the relationships between those data values,with just a small number of generic fields, is provided. Thus, at notime is a user or a developer required to specify the precise internallocation of the data either for the purpose of storage or retrieval.Thus, unlike known databases which require some form of registry, tolist the names of constituent tables and fields, and which is accessiblein code, the preferred system may be used without knowing in advance howthe data is stored and classified. The preferred system also providesaccess methods to add data to and retrieve data from the table.

The way in which data is represented in the preferred embodiment willnext be described. In order to simplify the description only data whichis text data will be considered.

A single entry of data in the table is called an Entity; the tableitself will now be referred to as the Entity Repository. In the case oftext data, an Entity is one or more characters or words of textrepresenting something which is to be described or might even be anempty string. For example, it might be an individual's name, or addressor the company they work for. Such Entities are stored in a single fieldof the Repository and each receive a unique identifier or index so thatthey may be distinguished from other Entities. The order in whichEntities are stored in the Entity repository does not need to bespecified since each Entity may be uniquely referenced by its index.

Relationships between stored Entities are explicitly defined by means ofa particular type of Entity called an Attribute. This is an array ofthree fields in the Repository each of which references a stored Entity.The Attribute acts as a relationship definition by associating threeEntities with one another. The particular nature of that relationship isleft entirely to the user entering the definition to decide. Because ofthe flexibility of the system, requiring no pre-classification of datatypes, the relationship may be completely arbitrary. A user maytherefore choose to associate three Entities in a relationshipdefinition which are apparently unconnected. The value in doing this isnot clear, but it is possible. Alternatively, and more usefully, a usermay choose to associate three Entities which although they appearunconnected, have some meaning to the user, such as the phone numbers ofthree friends. However, such relationship definitions are still notreally useful as they do not contain, or are not associated with anEntity which gives them meaning, such as friends' phone numbers in thelatter case. Thus, although the Attributes can in theory be used to holdany three Entities, even the same Entity three times, the principle andpreferred use of Attributes is to relate two different Entities in therepository together, with a third Entity describing the relationship inorder to provide information. In this arrangement, the first Entity ofthe Attribute, which we shall call the Subject Entity is the key item towhich a second piece of data is to be attached, the second Entity,called the Descriptor Entity, describes the relationship between the keydata in the Subject Entity and the subsequent piece of data, while thethird Entity, called the Data Entity is used to hold the informationrelated to the key in the Subject Entity. This terminology is introducedonly as a guide, to make referring to the three Entities whichconstitute an Attribute straightforward. It will be understood that theterminology does not itself describe or limit the Entities contained inthe Attribute.

A simple example of such an Attribute is one used to define a telephonenumber. In such a case, the key information in the Subject Entity of theAttribute might be a person's name, such as Robert Harris; the DataEntity will be a corresponding telephone number for that person, such as0123 456 7890, and the Descriptor Entity might be a string such astelephone number. It can be seen that, in this case, the DescriptorEntity also serves to describe the type of information held in the DataEntity, although this is not necessarily always true as will be seenlater.

Without the Descriptor Entity the relationship between the data held inthe Subject and Data Entities would be ambiguous. The number, forexample, might be a credit card number rather than a telephone number.For this reason, all of the Entities in an Attribute have to benon-null, otherwise the Attribute cannot adequately describe arelationship between two data items. However if the user wishes toassociate two Entities which do not have an obvious relationship orwishes not to state the nature of the relationship, the DescriptorEntity may be set values of unknown or ambiguous.

Attributes themselves are stored in the Entity Repository and receivethe same type of unique identifier that is received by the individualEntities. Thus, an Attribute in the Repository may also be treated as asingle Entity, which may be referenced by another Attribute. Where thereis just one Attribute being used to define a relationship, therelationship will be of only three Entities. Since Attributes may bereferred to by other Attributes more complicated relationships may bedefined as will be seen later. In the simplest case in which a singleAttribute refers to another single Attribute, the relationship will beseen to comprise five Entities in total. For each additional Attributethat is referred to, the relationship will comprise a further twoEntities, meaning that relationship definitions happen to only comprisean odd number of Entities.

A single Entity may be referred to by any number of Attributes to defineany number of relationships. This means that an item of data needs onlyto be stored in the Entity Repository once. To illustrate this point,consider the above example for Robert Harris.

In the example so far, it is clear that the number in the Data Entity isa telephone number because of the Descriptor Entity. However, it is notclear from the single Attribute what the entry Robert Harris actuallyrefers to. It could, for example, be the name of a Company, or the nameof an individual. By defining a second Attribute in which the Subject,Descriptor and Data Entities have the values Robert Harris, Employee andMetro Motors respectively, it is clear that Robert Harris is not acompany but a person and that he is employed by an Entity called MetroMotors. Thus, the recorded data for Robert Harris is increased. SinceRobert Harris is already an Entity stored in the repository, it need notbe redefined and can be re-used in the Subject Entity of the secondAttribute. Therefore, only two new Entities, having values Employee andMetro Motors, and one new Attribute need to be defined and issued withan index.

Thus, the two pieces of information that Robert Harris is employed byMetro Motors and that his telephone number is 0123 456 7890 may bestored in the Repository using two Attributes and just five Entities.

It is important to note that Entities are used to store data describingeither concrete or abstract things that are distinguishable to the usersor potential users in the real world, in addition to instances of data.An Entity can therefore represent anything that is nameable, such as aperson, a bank Account number or a file name, to name a few examples. Ifthere are two people called Robert Harris for whom there is informationstored it is not sufficient for distinguishing between them to use onlyone Entity to store their name. In order to preserve each of theirseparate identities in the table, as defined by Attribute relations,they will require separate Entity indices. Two Entities in respect ofRobert Harris are therefore needed.

The contrary case may arise where it is desirable to associate two ormore strings to a single Entity. An example would be where it isdesirable to refer to a single Entity by means of two or more stringsone of which might be an abbreviation or a synonym for the other.

In one embodiment, the system is implemented, at least in part as acomputer program product comprising a recording medium whish is readableby a computer. The recording medium is provided having program codestored thereon for execution on the computer. The program code definesan entity instance table into which instances of data can be entered forstorage, wherein each instance of data that is entered is allocated aunique identifier such that each instance can be uniquely referred to.The computer program product further defines a relationship definitiontable for storing a plurality of relationship definitions, eachrelationship definition having three data fields, each data heldcontaining the unique identifier of a selected instance of data storedin said entity instance table, whereby said relationship definitionrepresents a relationship between said selected instances of data.

The embodiment of the Entity Repository will next be described withreference to FIG. 1.

FIG. 1 shows the Entity Repository 2 according to the preferredembodiment of the invention comprising a table 4 made up of a number ofgeneric fields. The first field in the Repository is an ID field 6 andcontains the unique identifying index given to each Entity. Anynon-repeating, consistent series of numbers or letters may be used togenerate the next index for an Entity. Where only a single Repository isused, a series of consecutive numbers is sufficient to uniquely identifyeach Entity from another. However, if more than one Repository is used,as may be the case if Repositories are accessible via a network, anotheridentification system will be necessary to uniquely identify eachEntity. A suitable way of identifying each Entity in such a case is toassign it a Universal Unique Identifier (UUID) or a Globally UniqueIdentifier (GUID), both of which are known identification protocols. AUUID or GUID is a 128 bit hexadecimal number whose digits depend on theon the time of its creation, the location of its creation and otherfactors and so is unique from any other UUID or GUID in the world. Thus,an Entity added to a Repository in a network of Repositories may, bybeing assigned a UUID or GUID, be distinguished from any other Entity ina Repository anywhere in the world, whether it is connected on a networkor not.

The second field in the Repository is a binary type field 8 whichcontains a description of the type of the data encoded as an Entity.Possible binary types might be strings, integers, floats, or lists,structures or arrays of the same or similar primitive binary types, oreven more complicated types such as encodings of images or audio. A useof a list of strings, for example, might be to provide for synonymspointing to a single Entity. It should be noted however that the memberstrings have no separate identity in the internal context of the system.

The third field in the Repository is the Entry field 10. This fieldcontains a reference to a location in memory where the data for thatEntity is stored. The Repository does not itself physically store thedata of an Entity. This is stored elsewhere in the memory of the systemand only the memory address or reference is stored in the Repository.

An Entity 20, according to the preferred embodiment is definedcompletely by a row in the Repository which contains a unique index, anindicator of the binary type of the data and a reference to the locationof the data in memory.

The Repository 2 also comprises fourth, fifth and sixth fields whichtogether define an Attribute by individually storing the unique indicesof Entities which are to be related to each other.

The fourth field 12 holds the unique index of the Subject Entity, thefifth field 14, the Descriptor Entity and the sixth field 16, the DataEntity. An Attribute 22, according to the preferred embodiment, isdefined completely by a row in the Repository which contains a uniqueindex and Entity indices in all of the Subject, Descriptor and DataEntity fields.

Table 4 of the Repository may contain additional fields for purposes ofinternal house-keeping, although these are not shown in FIG. 1. One suchfield not shown in FIG. 1 is a field for storing an ignore flag. In thecase of an Attribute, this may be used to cause the attribute to beignored in a search of the Repository. This allows the Attribute to beeffectively deleted, without actually destroying the informationcontained in the Attribute. Other examples of use of additional fieldsas flags might be a data verified by independent sources' flag or anarchived flag, although such possible uses will not be discussed here.

The preferred system provides input methods which allow new Attributesand Entities to be added to the Repository, issued with the nextavailable index, and receive data to be stored. The preferred systemalso provides methods that check the newly inputted data in an Entityagainst existing Entities in the Repository in order to avoidunnecessary duplication. In the case where a user attempts to input adata item already stored in an Entity of the Repository, the index andthe value of the matching Entity are first returned so that the user candecide whether they wish to continue with the input. Thus Entitiesalready existing in the Repository can be re-cycled when definingAttributes. Methods are also provided to return the indices of Entitiesthat contain strings or values that match a given input term. TwoEntities with the same data value can however have different indices asmight be desirable, for example, if a user wishes to store data relatingto two individuals with the same name. In such a case, in order topreserve the distinction between the two individuals it will benecessary to maintain different indices for the Entities storing theiridentical names so that different relationships for them can be definedby way of Attributes. The methods outlined above may be implemented withknown data manipulation and search techniques and so shall not bedescribed here.

FIG. 2 shows an example data set comprising a number of Attributesstoring different data relating to cars and car manufacturers. It willbe appreciated that in actuality, the entry in each of the columns willbe the unique index of an Entity stored in the Entity repository and nota readable term such as Ferrari. For convenience however, FIG. 2 showsthe data held in the memory location referenced by the Entity specifiedin the Attribute.

The data set contains different kinds of information, as is evident frominspection of the second column of FIG. 2, corresponding to theDescriptor Entity of an Attribute, which specifies manufacturer, madeby, based in, seats and cost. Attributes with the same Descriptor Entitybut different Subject and Data Entities effectively correspond toentries in a single, simple table. For example, the Attributes withDescriptor Entity manufacturer may be thought of as defining amanufacturers table in which Ferrari and sports cars, Porsche and sportscars, Lotus and sports cars and Rolls Royce and Luxury Saloons are theentries in the rows and columns. Thus it will be seen that the preferredsystem provides a way of representing the relational information betweendata items in a way which does not require the formalised definition oftables according to the data being stored. Instead a relationship,between data is asserted by a single term, the Descriptor Entity, and bythe explicit relating of data items in an Attribute. It will be shownlater in the description how a table of more than two columns may beeasily reproduced by the preferred system.

It will be noted that, unlike databases in which the tables may beconsidered to provide an implicit scheme of classification, this systemdoes not provide either an implicit or intrinsic scheme forclassification of data. Instead, an explicit means for classifying datawill be described later.

The preferred system provides methods for searching the Attributes inthe record set for those with entity values that match those specifiedin a query. A method of entering a search term comprising three Entitiesto be matched is provided to make the query. Wild card values may beentered in the search term and may be matched to all possible values ofan Entity. The results of the search method will be the unique indicesof the Attributes with Entity values that matched those specified in thesearch term. From these indices the three Entity values of all of thematching Attributes may then be output.

FIG. 3 a shows this record set being queried for all Attributes thatmatch an input search term. In this case the search term is specified inthat the Descriptor Entity must define a manufacturer and the DataEntity must contain Sports car. The value of the Subject Entity is leftunspecified, as indicated by the asterisk. The search is clearly for amanufacturer of Sports cars.

The search may be presented to the system using the example pseudo-codeas set out below. It will be appreciated that the outline pseudo-code isintended to be representative of the functionality which is describedbelow and which may be implemented by any competent programmer.

Blank Query { New Triple1: SetCriteria(1,2, manufacturer)SetCriteria(1,3, Sports Car) }The above code defines a Query, to present to the record set, whichconsists of a single search term called Triple1. The three entries ofthe search term, which are to be matched to the three Entities ofAttributes in the record set are defined using the SetCriteria function.This function takes three parameters; the first is an identifier for thesearch term, in this case the number 1 since there is only one searchterm in the Query; the second is the position in the search term of theEntity we are specifying, in the code above we specify that manufactureris the second, that is the Descriptor Entity, and Sports Car is thethird, or the Data Entity; the third parameter is the Entity we aretrying to match to. In the above code the Entity is shown as the actualtext of the Entity itself, but it may just as easily be the uniqueidentifier of the Entity whose value we wish to match. The default entryfor a position in the search term is the wild card marker which matchesto all Entities in the record set. Thus, in the example above, we do notneed to specify a SetCriteria for the first position in the search term,as we wish this to be a wild card. On executing the above query, theAttributes of the record set are stepped through sequentially, and anyAttributes in which all three Entities have values that match those ofthe search term are returned as an output. The output may be just theunique identifier of the matching Attributes or for convenience, mayadditionally include the text values of the Attribute Entities. If anyAttributes are flagged as ones to be ignored they will be not beconsidered in the search. Three manufacturers of Sports cars arereturned, these being Ferrari, Porsche and Lotus.

Search terms may be entered in terms of text, or in terms of the uniqueidentifiers of Entities. In this context, therefore, a match between anEntity and the entry of a search term means both a match between thetext string of an Entity and that entered in the search, and a matchbetween the unique identifiers of Entities.

FIG. 3 b shows a second query bring made of the same record set in whichthe search term specifies all Attributes in which the Descriptor Entitycontains the value made by and the Data Entity contains the valueFerrari. Example code for this query is shown below.

Blank Query { New Triple2: SetCriteria(2,2, made by) SetCriteria(2,3,Ferrari) }Two Attributes which define the cars Dino, and Maranello as cars thatare made by Ferrari are returned.

The output returned by the system is more useful if the outputs of twoor more queries can be combined. In the case of the output produced sofar it is clear to a user that a useful association can be made betweenthe Dino car Attribute returned in the second query and the FerrariAttribute returned in the first query, since the Subject and DataEntities of the two Attributes have a value that is in common, namelyFerrari as shown in FIG. 3 c. An information record for the Dino car maybe inferred from the output produced so far that reads The Dino car ismade by Ferrari who manufacture Sports Cars.

Next will be described how the system may be instructed to combine theinformation in two Attributes to produce a more useful output.

A profile of all cars manufactured by Sports car manufacturers may bebuilt up by processing the double query shown schematically in FIG. 4 a.Two search terms are applied to search the record set, with theadditional condition being specified that the Data Entity of the made bysearch must match the Subject Entity of the manufacturer of sports carssearch. The condition that the Entities be identical is represented bythe X in FIG. 4 a, and is known as a binding condition. Identical, inthis case, will be understood to mean that the string or value of theEntity is identical or that the identifier of the Entity is identical.When specifying binding conditions, it is preferable however that onlythe unique identifiers of Entities are matched so that a positive matchindicates that the same Entity has been found in both searches. This iscalled strong binding and guarantees that the information retrieved in asearch is consistent and that it relates to a single thing.

However, it is conceivable that weak binding in which matches betweenthe text strings of Entities are deemed to satisfy the binding conditionmay also find an application. In such a case, information relating tosynonym Entities will also be retrieved, which may or may not be useful.

Example code for the compound query is shown below.

Blank Query { New Triple1: SetCriteria(1,2, made by) New Triple2:SetCriteria(2,2, manufacturer) SetCriteria(2,3, Sports Cars)SetBinding(1,3,2,1) }

The first three lines of the Query declaration define two search termsto be applied to the record, using the function SetCriteria, while thelast line specifies a binding condition that must be fulfilled betweenthe results of the two searches when they are performed in order todetermine the output. The syntax of the SetBinding function will bedescribed later.

The query is stepped through sequentially so that the search specifiedby the term Triple1 is processed first, followed by the search specifiedby the term Triple2, followed by the binding condition. It will beappreciated that a new search term in no way related to earlier searchterms in a query will give rise to an ambiguous if not meaninglessquery. As an example of this, the two separate searches considered sofar, that is the made by search and the manufacturer of sports carssearch, give rise to two distinct information sets which becamemeaningful as a single information set only when they are integratedinto a single information set. For a compound query to be well definedtherefore, it is a sufficient condition that every search term declaredas a Triple must be bound to at least one earlier search term Triple.

Referring to FIG. 4 b, the first search term, called Triple1 in the codeabove, specifies only that the Descriptor Entity of the Attribute hasthe value made by. The entries of the search term corresponding to theSubject and Data Entities of Attributes are not specified in thedefinition, so that they remain as wild card markers and allow allAttributes that satisfy the a made by b relationship to be returned. Thesearch term is shown schematically on the left of FIG. 4 b, with theresults of processing this search term shown below. The data beingconsidered in this example only contains information about carmanufacturers so that by specifying that the Descriptor Entity has thevalue made by only those Attributes of the form some car, made by, somemanufacturer are returned. In a typical data set, however, theinformation contained will not be limited to that pertaining to cars, sothat a search of the data set using the search term Triple1, as definedabove, will result in lengthy list of Attributes of the form “some x,made by, some y”, being returned the majority of which are of nointerest at all to the person making the search. At this stage thereforethe results of the search are stored in memory and nothing is yet outputto the screen of the user.

The second search term, Triple2 specifies that the Descriptor Entity hasthe value manufacturer and that the Data Entity has the value SportsCars. The value of the Subject Entity is not specified so that thedefault wild card marker is used. The second search term is processed,and the results of the search are stored in memory. In FIG. 4 b, thesecond search term is shown schematically on the right side of thediagram with the results of the search underneath. As before, threemanufactures of sports cars are returned.

The system now processes the binding condition encoded in the functionSetBinding. The function takes four parameters, as indicated below.

SetBinding(TripleA, HoleA, TripleB, HoleB)

Parameters TripleA and TripleB represent the identifiers of the firstand second search terms applied to the data set, and in fact refer toall of the matched Attributes returned for each of those searches andheld in memory. HoleA and HoleB refer to the positions of an Entity inthe returned Attributes of the first and second searches that we wish tomatch, and are therefore simply the numbers 1, 2 or 3, referringrespectively to the position of the Subject Entity, the position of theDescriptor Entity, and the position of the Data Entity. The value 0 mayalso be used to refer to an entire Attribute which is to be matched aswill be seen later. The function asserts an equivalence between theEntities in HoleA of the Attributes returned in the first search, andthe Entities in HoleB of the Attributes returned in the second search,and returns only those pairs of Attributes for which the assertion istrue. When declaring set binding conditions, logical operators such asAND, NOT and OR may be used in conjunction with the Set Bindingfunctions to define more complex queries, though these will not beconsidered in any more detail here.

In the example compound query described above, and illustrated in FIG. 4a, we wish to output only those Attributes which satisfy the firstsearch term, that is that they be in the form *.made by.* (where forconvenience and readability the . denotes delineation between the threeparts of the search term and where the * denotes a wildcard) and whichhave a Data Entity which is the same as the Subject Entity of thoseAttributes that satisfy the second search term, that is Attributes inthe form *.manufacturer. Sports Cars.

This condition is encoded with the function SetBinding as follows.

SetBinding(1,3,2,1)

The first parameter 1 refers to the results of the first search term,Triple1, shown on the left of FIG. 4 b; the second parameter 3,indicates the we are matching the Data Entity of these Attributes to oneof the Entities of the Attributes returned in the second search. Theresults of the second search, Triple 2, are referred to by the value 2for the third parameter in the function, while the value of 1 for thefourth parameter indicates that it is the Subject Entity of theAttributes in the second set that we wish to match to the Data Entity ofthe Attributes in the first set.

Processing the query, as defined above, produces the output shown inFIG. 4 c. From all possible pair-wise combinations of the output in thefirst list and the three output in the second list only four satisfy thecondition and are finally output. The system may format the results ifso desired to be output in a more compact form such as those shown inFIGS. 4 d and 4 e.

It will be appreciated that the way in which the comparison between thesearch results is made, as it is described above, is quite simple and isjust one way in which the processing of the search condition may beachieved. Other methods or search algorithms may also be used.

FIG. 5 shows a second example set of data which will be used todemonstrate how three search terms and two conditions may be used togenerate more complex output. The data in the data set of FIG. 5 relatesto individuals, the company they are employed in and the address of thatcompany.

FIG. 6 a shows the search terms and conditions used in the example tosearch the data set. We wish to return from the data set the names ofthe individuals, the company that they are employed in and the addressof the company. This query might be used to produce a mailing list forexample.

The first search term in the three is input with the value company forthe Descriptor Entity, with the values of the subject and Data Entitiesbeing left unspecified. The results of this query will be all thoseAttributes with the string company as the Descriptor Entity. In theexample record set shown in FIG. 5, these are all of the form“individual name.company.company name”.

The second search term is input with the string address for theDescriptor Entity, while the subject and the Data Entities values areleft unspecified. The binding condition is that the value of the SubjectEntity of Attributes returned in the second search must match the valueof the Subject Entity returned in the first search. This condition isrepresented by the letter C in FIG. 6 a. For the example record set ofFIG. 5, this combined query will only therefore match Attributes in thefirst set to Attributes in the second set of the form “companyname.address.*”

As a supplement to the address we also wish to know the correspondingpostal code (zipcode) for the address. A third search term is also inputtherefore which specifies that the Descriptor Entity has the valuepostcode. The values of the Subject and Data Entities are leftunspecified. On applying this search term to the data set, the postcodes for all addresses listed in the data set are returned. Thecondition that the value of the Subject Entity in the results of thethird search must match the Data Entity of the results in the secondsearch is stipulated so that only those addresses found in the secondsearch will return a post code P. This condition is represented by thevalue A in FIG. 6 a.

Example code for this query is shown below.

Blank Query { New Triple1: SetCriteria(1,2, Company) New Triple2:SetCriteria(2,2, Address) New Triple3: SetCriteria(3,2, PostCode)SetBinding(1,3,2,1) SetBinding(2,3,3,1) }The code in this case requires the use of a second binding conditiondefined by the SetBinding function. Executing the first SetBindingfunction results in a set of Attributes-pairs being returned thatsatisfy the first binding condition. These results are not output atthis stage but are held in memory in order to process the second bindingcondition. The results of the third search term *.PostCode.* are thencompared with the second Attribute of the Attribute-pairs output fromprocessing the first binding condition in order to process the secondbinding condition.

The final results of the search are shown in FIG. 6 b slightly formattedto avoid repetition of Entities with identical values. The unformatteddata returned for a single query is shown by way of example in FIG. 6 c.The second attribute is displaced slightly for clarity.

The results illustrated in the above example could have been obtainedvia a search of a conventional database containing the information in asingle table, or could have been achieved via combined searches of aconventional database with three tables, namely Company, Address andPostcode. However, with conventional databases the format of the tablesmust be known in advance of the query.

The preferred embodiment of the present invention however may be thoughtto construct a table in response to each search query and then combinethe results to produce the desired output. The preferred system itemiseseach piece of information in a single attribute and uses one or more ofthe Subject, the Descriptor or Data Entities of the Attribute and one ormore binding conditions to organise the information output in responseto a search query. The Attributes and Entities themselves are stored inthe Repository in no particular order.

The user therefore has the capability to access any or all of the dataheld in the repository and specify exactly what data is to be returnedand the order in which that data is to be returned. The preferred systemachieves this without the need for organisation of the data within theRepository, providing a flexible system to which new records may beadded without the need for prior design of specific fields to containthe new data.

It will be noted that in the above example, the search was simplified byconsidering only a limited and contrived data set, in which theinformation had been recorded in a straightforward and intuitive way,that is to say that we could assume that the value of company for theDescriptor Entity implied that the value of the Data Entity was in facta company name. However, in more general circumstances, with a muchlarger Repository of information to which there might be multiplecontributors, this will not be the case and the fact that the DescriptorEntity contains the string company will not necessarily have any bearingon the contents of the Subject or Data Entities. The preferred systemdoes not provide any intrinsic classification of the data stored inEntities into types, and instead a user declares a data relationship atinput. The declaration may or may not have meaning.

In the case of databases, the intuitive process of classification ofdata is formalized by the requirement to specify tables in advance. Theadvantage of such an approach is that all elements classifiable into aparticular type, referred to as a semantic type, may be found in oneplace. The disadvantage is that real world complexity gives rise toinnumerable and often inconsistent classification schemes. The existenceof such schemes must then be known in advance of data entry orretrieval.

By contrast, the preferred system uses a single extremely compact schemeof universal generality. The advantage is that structures of informationdo not need to be known in advance, allowing flexible and unrestrictedentry of a multitude of data of any semantic type without therequirement to declare the semantic type of the data in advance. Whereit is useful to declare the nature or semantic type of data, and providea means of classification, this may be done through a furtherdeclaration of an Entity such as is a or type of. Referring to therecord set of FIG. 5, in order to explicitly and unambiguously declareWidgets Inc. to be a company, for example, would require the use of thenew Entity in the input of a further Attribute of the form “Widgets Inc.is a company”.

To further illustrate how the preferred system organises the results inresponse to a search query, a second example using the same record setbut a different searching strategy will be considered.

In the first example, the values of the Subject and Data entities ofadjacent search terms were required to match so that each subsequentitem of information in an Attribute relates to the previous Attribute ofinformation in the chain of results.

In the second example we wish to collate the information we have on aparticular individual called John Smith. Once again a search term isused to retrieve data specified by the value of the Descriptor Entity,but this time we specify that the value of the Subject Entity is alwaysthe same. This is represented in FIG. 7 a by the value A.

The value A is understood to be a wild card so that all sets of threeAttributes with the same subject and with Data Entities defined ascompany position and department will be returned. The values C, P and Dalso indicate wild card entries in the search. The search query in thiscase effectively constructs a table of four columns containing the nameof the individual, the company the individual works for, their positionand their department. Example code for this query is shown below.

Blank Query { New Triple1: SetCriteria(1,2, Company) New Triple2:SetCriteria(2,2, Position) New Triple3: SetCriteria(3,2, Department)SetBinding(1,1,2,1) SetBinding(2,1,3,1) }

The results of the search are shown in FIG. 7 b slightly formatted toremove repetition of values. The unformatted result of the search isshown in FIG. 7 c.

At no stage have the Attributes or Entities contained in the record setbetween partitioned or organised into this table structure shown in FIG.7 b or 7 c, rather the results are formatted and arranged as a table foroutput in response to a search query being put to the Repository.

Any number of other tables are possible and can be made simply by addingAttributes with new Description Entities to the repository. The systemis therefore capable of considerable expansion and adaptability.

In the examples considered so far, Attributes of the data set have beendescribed with reference only to the unique identifiers of threeEntities holding a single piece of data, however, as mentioned earlier,since each Attribute is itself given a unique identifier in the tableand can therefore also be thought of as an Entity, it is possible for anAttribute to be defined which refers to one or more other Attributes.Such an Attribute is shown in FIG. 1 as Attribute 24. The Attribute isstored as Entity number 8, and declares Attribute number 4 as itsSubject Entity, Entity number 7 as its Descriptor Entity and Entitynumber 6 as its Data Entity. By referring to one or more otherAttributes more complex information can be stored, as will beillustrated with reference to FIG. 8.

FIG. 8 shows the contents of an example data set in which the shareprice of the company Metro Motors is stored. The construction of theRepository is simplified slightly for convenience from that shown inFIG. 1, but it will be understood to operate in the same way. The uniqueidentifier of each Entity is held in the first column, the reference tothe memory location where the data of the Entity is stored in thesecond, although in FIG. 10 the actual text string of the entity isshown, while the third, fourth and fifth columns store the three Entityindices necessary to define an Attribute. In FIG. 8 the binary typecolumn shown in the Repository of FIG. 1 has been omitted and anadditional column, to the right, has been introduced to show theinformation stored in the Attributes of the data set.

Referring to FIG. 8 it will be seen that to record the share priceinformation of Metro Motors for a given year five Entities are used. Thefirst five Entities of the data set have values Metro Motors, SharePrice, 1.60, in year and 1998 respectively, and are related to eachother by two Attributes with Entity indices 6 and 7. Attribute number 6asserts a relationship between Entities number 1, 2 and 3 of the formMetro Motors.Share Price., 1.60, as is shown in the adjacent column ofthe table in FIG. 8. Attribute number 7 asserts a further relationshipbetween Attribute number 6 and the Entities number 4 and 5, so that thecompleted relationship is of the form (Metro Motors. share price.,1.60.) in year.1998, as shown in the adjacent column of the table inFIG. 8. The parentheses denote an Attribute which is an Entityparticipating in a further Attribute.

Entering the share price information for a subsequent year, 1999, onlyrequires the use of a further two Entities and a further two Attributes,as the Entities with values Metro Motors, Share Price and in year can bere-used. Thus Entity number 8, records the share price in 1999 of, 1.70,and Entity number 9 records the string 1999. Attribute number 10,asserts a relationship between Entities number 1, 2 and 8, to make thestatement Metro Motors.Share Price., 1.70″ and Attribute number 11,asserts a relationship between Attribute number 10 and the Entitiesnumber 4 and 9, to record (Metro Motors. share price., 1.70).inyear.1999″. By referring to other Attributes in the data set complexstatements of information can be stored.

Data sets in which Attributes refer to other Attributes can be queriedin the same way as described above. For example, searching the data setfor Metro Motor share prices may be achieved by entering the followingquery.

Blank Query { New Triple1: SetCriteria(1,1, Metro Motors)SetCriteria(1,2, Share Price) }The result of this query will be only Attributes number 6 and 7, whichstate Metro Motors. Share Price., 1.60 and Metro Motors. Share Price.,1.70″ respectively. The Attribute number 7 and 11 which specify both theprice and the year information are not however returned during such asearch, as these Attributes refer to the index of another Attribute fortheir first Entity, and no match can therefore be made with the searchterm which is trying to match the first Entity to another Entity withthe string Metro Motors.

It is possible however to search for Attribute in a query, by explicitlyspecifying the Attribute index in the search term. For example,following the query above, Attribute numbers 6 and 7 will be returnedand their Attribute indices will therefore become known. In order,therefore to return the Attribute which contains both the share priceinformation for 1998 the following Search query may be used.

Blank Query { New Triple1: SetCriteria(1,1,6) SetCriteria(1,2,4)SetCriteria(1,3,5) }In the above code, the Entity indices of the data are used to declarethe search term. The result of the above query will returnAttribute-Entity number 7 which contains Attribute 6 in its firstposition, Entity number 4, that is the Entity with string in year, inits second position and, Entity number 5, that is the Entity with string1998 in its third position.

Using the Entity indices explicitly as the SetCriteria matching termsallows compound queries to be constructed which can handle references toother Attributes. The following code illustrates how a single query maybe used to retrieve only those Attributes containing the share price andyear information.

Blank Query { New Triple1: SetCriteria(1,1, Metro Motors)SetCriteria(1,2, Share Price) New Triple2: SetCriteria(2,2, in year)SetBinding(1,0,2,1) }The SetCriteria functions search terms may be defined either by thestring of the Entities to be matched or explicitly by entering theappropriate Entity indices in the same way as before. In this queryhowever, the binding condition employed, as expressed by the SetBindingfunction, is that the Attribute returned in the first search appear asthe first referenced Entity of the Attributes returned in the secondsearch. This condition is expressed by entering the value 0 for thesecond parameter of the SetBinding function in order to refer to thewhole of the returned Attribute rather than just one of its singlecomponent Entities.

The results of the above query will be only Attributes 7 and 11containing both the share price and year information.

Although the invention has been described with reference to a specificpreferred system, many variations of the preferred system will beunderstood to fall within the scope of the invention. Furthermore, theAttributes and Entities may be stored in the same Repository or inseparate Repositories. The Repository may hold the data of Entitiesitself or references to memory locations where the data is storedexternal to the Repository. Also, although the examples of the datastored in the Repository have been solely examples of text data, that isEntities with the binary type string, it will be appreciated that dataof other binary types may also be stored, such as in particular,integers or other numeric types. Access methods to perform logical ormathematic operations on the contents of Entities or Attributes may alsobe provided.

It will also be appreciated that the way in which the data is stored asa multitude of Entities and Attributes may be achieved without the useof a table. Entities and Attributes could, for example, be encoded asobjects of an object-orientated programming language or in anyequivalent ways provided by any other programming language.

1. A method of storing data, comprising: providing an entity instancetable into which instances of data can be entered, said entity instancetable being stored in a memory of a computer; receiving instances ofdata and storing the instances in said entity instance table; allocatinga unique identifier to each instance of data received for storage insaid entity instance table, such that each instance can be uniquelyreferred to; providing a relationship definition table for storing aplurality of relationship definitions, each relationship definitionhaving three data fields, and said relationship definition table beingstored in the memory of said computer; and receiving three uniqueidentifiers of selected instances of data stored in said entity instancetable and storing the three unique identifiers as a relationshipdefinition in said relationship definition table, a relationship beingdefined by exactly three unique identifiers and each of said exactlythree unique identifiers being contained in a respective one of saidthree data fields of said relationship definition.
 2. The method ofclaim 1 wherein providing an entity instance table comprises: comparingan input instance of data that has been received for storage withexisting instances of data already stored in said entity instance table;returning the unique identifier of an existing instance of data storedin said entity instance table, if the input instance of data isidentical with said existing instance of data; prompting a user toidentify whether the existing instance of data and the input instance ofdata which is identical are to be associated with one another; andallocating, if the user indicates that the existing instance of data isnot to be associated with the input instance of data, a uniqueidentifier to the input instance of data and storing the uniqueidentifier to the input instance of data in the entity instance table.3. The method of claim 1, further comprising allocating a uniqueidentifier to at least one relationship definition entered into saidrelationship definition table, such that the at least one relationshipdefinition can be uniquely referred to.
 4. The method of claim 3 whereinreceiving three unique identifiers comprises receiving for storage in arelationship definition, in place of the unique identifier of aninstance of data the unique identifier of a relationship definitionstored in said relationship definition table, such that the relationshipdefinition represents a relationship between an odd number, greater thanor equal to five, of instances of data stored in said entity instancetable.
 5. The method of claim 1 wherein an instance of data is used torepresent a single nameable entity, or a relationship between entities.6. The method of claim 5 wherein one of the unique identifiers containedin a relationship definition refers to instances of data that representrelationships between entities.
 7. The method of claim 1 wherein storingthe instances in said entity instance table comprises storing theinstances in said entity instance table with an indicator of the binarytype of the data.
 8. A method of storing and retrieving data comprising:providing an entity instance table into which instances of data can beentered, said entity instance table being stored in a memory of acomputer; receiving instances of data and storing the instances in saidentity instance table; allocating a unique identifier to each instanceof data received for storage in said entity instance table, such thateach instance can be uniquely referred to; providing a relationshipdefinition table for storing a plurality of relationship definitions,each relationship definition having three data fields, and saidrelationship definition table being stored in the memory of saidcomputer; receiving three unique identifiers of selected instances ofdata stored in said entity instance table and storing the three uniqueidentifiers as a relationship definition in said relationship definitiontable, a relationship being defined by exactly three unique identifiersand each of said exactly three unique identifiers being contained in arespective one of said three data fields of said relationshipdefinition; receiving a search query, having three data fields eachcontaining a search parameter for matching to the contents of thecorresponding one of said three data fields of said relationshipdefinitions stored in said relationship definition table; comparing eachof said search parameters with the contents of the corresponding datafield of said relationship definition stored in said relationshipdefinition table; and retrieving, as a set of results, only thoserelationship definitions in which the contents of the three data fieldsmatch said three search parameters, wherein said search parameter caninclude a unique identifier or a match-to-all search parameter, whichmatches to the corresponding data field in the relationship definitionregardless of the contents of said data field.
 9. The method of claim 8,further comprising: entering a second search query, having three datafields each containing a search parameter for matching to the contentsof the corresponding one of said three data fields of said relationshipdefinitions stored in said relationship definition table; specifying theposition of a data field in the first search query and the position of adata field in the second search query for linking the set of resultsretrieved for the first search query to results retrieved for the secondsearch query; comparing each of said search parameters of said secondsearch query with the contents of the corresponding data field in arelationship definition stored in said relationship definition table;retrieving, as a second set of results, only those relationshipdefinitions in which the contents of the three data fields match saidthree search parameters of said second query, and in which a uniqueidentifier in the data field specified for the second search query, isidentical to a unique identifier in the data field specified in respectof the first search query and retrieved in the first set of results; andcombining the first set of results and the second set of results to forma third set comprising every pair-wise combination of relationshipdefinitions for which the unique identifier of the instance of data atthe position specified for the first search query and the positionspecified for the second search query is the same.
 10. The method ofclaim 9 wherein the data field specified for the first search query andthe data field specified for the second search query both contain amatch-to-all search parameter.
 11. The method of claim 8 furthercomprising allocating a unique identifier to at least one relationshipdefinition entered into said relationship definition table, such thatthe at least one relationship definition can be uniquely referred to.12. The method of claim 11 wherein receiving three unique identifierscomprises receiving for storage in a relationship definition, in placeof the unique identifier of an instance of data, the unique identifierof a relationship definition stored in said relationship definitiontable, such that the relationship definition represents a relationshipbetween an odd number, greater than or equal to five, of instances ofdata stored in said entity instance table.
 13. The method of claim 12wherein receiving a search query comprises receiving the uniqueidentifier of a relationship definition stored in said relationshipdefinition table as a search parameter.
 14. The method of claim 8wherein an instance of data is used to represent a single nameableentity, or a relationship between entities.
 15. The method of claim 14wherein one of the unique identifiers contained in a relationshipdefinition refers to instances of data that represent relationshipsbetween entities.
 16. The method of claim 8 wherein storing theinstances in said entity instance table comprises storing the instancesin said entity instance table with an indicator of the binary type ofthe data.
 17. A method of storing data, comprising: providing an entityinstance table into which instances of data can be entered, said entityinstance table being stored in a memory of a computer; receivinginstances of data and storing the instances in said entity instancetable; allocating a unique identifier to each instance of data receivedfor storage in said entity instance table, such that each instance canbe uniquely referred to; receiving three unique identifiers of selectedinstances of data stored in said entity instance table and storing thethree unique identifiers as a relationship definition in said entityinstance table, a relationship being defined by exactly three uniqueidentifiers, said relationship definition having three data fields andeach of said exactly three unique identifiers being contained in arespective one of said three data fields; allocating a unique identifierto a relationship definition received for storage in said entityinstance table, such that the unique identifier to a relationshipdefinition can be uniquely referred to; and receiving three uniqueidentifiers for storage as a second relationship definition, wherein atleast one of the unique identifiers is that of a relationship definitionalready stored in said entity instance table, said second relationshipdefinition thereby representing a relationship between an odd number,greater than or equal to five, of instances of data stored in saidentity instance table.
 18. The method of claim 17 wherein receivinginstances of data and storing the instances in said entity instancetable comprises: comparing an input instance of data that has beenreceived for storage with existing instances of data already stored insaid entity instance table; returning the unique identifier of anexisting instance of data stored in the entity instance table, if theinput instance of data is identical with said existing instance of data;prompting a user to identify whether the existing instance of data andthe input instance of data which is identical are to be associated withone another; and allocating, if the user indicates that the existinginstance of data is not to be associated with the input, a uniqueidentifier to the input instance of data and sorting the uniqueidentifier to the input instance of data in the entity instance table.19. The method of claim 17 wherein an instance of data is used torepresent a single nameable entity, or a relationship between entities.20. The method of claim 19 wherein one of the unique identifierscontained in a relationship definition refers to instances of data thatrepresent relationships between entities.
 21. The method of claim 17wherein storing the instances in said entity instance table comprisesstoring the instances in said entity instance table with an indicator ofthe binary type of the data.
 22. A method of storing and retrievingdata, comprising: providing an entity instance table into whichinstances of data can be entered, said entity instance table beingstored in said memory of said computer; receiving instances of data andstoring the instances in said entity instance table; allocating a uniqueidentifier to each instance of data received for storage in said entityinstance table, such that each instance can be uniquely referred to;receiving the unique identifiers of three instances of data stored insaid entity instance table and storing the unique identifiers as arelationship definition in said entity instance table, a relationshipbeing defined by exactly three unique identifiers, said relationshipdefinition having three data fields and each of said exactly threeunique identifiers being contained in a respective one of said threedata fields; allocating a unique identifier to a relationship definitionreceived for storage in said entity instance table, such that therelationship definition can be uniquely referred to; receiving threeunique identifiers for storage as a second relationship definition,wherein at least one of the unique identifiers is that of a relationshipdefinition already stored in said entity instance table, said secondrelationship definition representing a relationship between an oddnumber, greater than or equal to five, of instances of data stored insaid entity instance table; receiving a search query, having three datafields each containing a search parameter for matching to the contentsof the corresponding one of said three data fields of said relationshipdefinitions stored in said entity instance table; comparing each of saidsearch parameters with the contents of the corresponding data field ofsaid relationship definition stored in said entity instance table; andretrieving, as a set of results, only those relationship definitions inwhich the contents of the three data fields match said three searchparameters, wherein said search parameter can include a uniqueidentifier or a match-to-all search parameter which matches to thecorresponding data field in the relationship definition regardless ofthe contents of said data field.
 23. The method of claim 22 furthercomprising: entering a second search query, having three data fieldseach containing a search parameter for matching to the contents of thecorresponding one of said three data fields of said relationshipdefinitions stored in said entity instance table; specifying theposition of a data field in the first search query and the position of adata field in the second search query for linking the set of resultsretrieved for the first search query to results retrieved for the secondsearch query; comparing each of said search parameters of said secondsearch query with the contents of the corresponding data field in arelationship definition stored in said entity instance table;retrieving, as a second set of results, only those relationshipdefinitions in which the contents of the three data fields match saidthree search parameters of said second query, and in which the uniqueidentifier of the instance of data, or of the relationship definition,in the data field specified for the second search query, is identical toa unique identifier of an instance of data, or of a relationshipdefinition, retrieved in the first set of results at the positionspecified for the first search query; and combining the first set ofresults and the second set of results to form a third set comprising theunique identifiers for the two relationship definitions of everypair-wise combination of relationship definitions for which the uniqueidentifier of the instance of data at the position specified for thefirst search query and the position specified for the second searchquery is the same.
 24. The method of claim 18 wherein the data fieldspecified for the first search query and the data field specified forthe second search query both contain a match-to-all search parameter.25. The method of claim 22 wherein an instance of data is used torepresent a single nameable entity, or a relationship between entities.26. The method of claim 25 wherein one of the unique identifierscontained in a relationship definition refers to instances of data thatrepresent relationships between entities.
 27. The method of claim 22wherein storing the instances in said entity instance table comprisesstoring the instances in said entity instance table with an indicator ofthe binary type of the data.
 28. A system for storing data, comprising:a computer system having a processor and a memory; an entity instancetable, stored in said memory of said computer system, into whichinstances of data can be entered for storage, wherein each instance ofdata that is entered is allocated a unique identifier such that eachinstance can be uniquely referred to; and a relationship definitiontable, stored in said memory of said computer system, for storing aplurality of relationship definitions, a relationship being defined byexactly three unique identifiers, each relationship definition havingthree data fields, each of said exactly three unique identifiers beingcontained in a respective one of said three data fields of saidrelationship definition.
 29. The system of claim 28, further comprisinga comparator for comparing an input instance of data that has beenentered for storage with existing instances of data already stored insaid entity instance table, and returning the unique identifier of anexisting instance of data stored in said entity instance table, if theinput instance of data is identical with said existing instance of data;a user-interface for prompting a user to identify whether the existinginstance of data and the input instance of data which is identical areto be associated with one another, wherein if the user indicates thatthe existing instance of data is not to be associated with the inputinstance of data, a unique identifier is allocated to the input instanceof data, and the instance of data is stored in the entity instancetable.
 30. The system of claim 28 wherein a unique identifier is alsoallocated to at least one relationship definition entered into saidrelationship definition table, such that the at least one relationshipdefinition can be uniquely referred to.
 31. The system of claim 30wherein in a relationship definition, can contain in place of the uniqueidentifier of an instance of data, the unique identifier of arelationship definition stored in said relationship definition table,such that the relationship definition represents a relationship betweenan odd number, greater than or equal to five, of instances of datastored in said entity instance table.
 32. The system of claim 28 whereinan instance of data is used to represent a single nameable entity, or arelationship between entities.
 33. The system of claim 32 wherein one ofthe unique identifiers contained in a relationship definition refers toinstances of data that represent relationships between entities.
 34. Thesystem of claim 28 wherein said entity instance table includes a binarytype field associated with each instance of data and each instance ofdata stored in said entity instance table is stored with an indicator ofthe binary type of the data in the corresponding binary type field. 35.A system for storing and retrieving data comprising: a computer systemhaving a processor and a memory; an entity instance table, stored insaid memory of said computer system, into which instances of data can beentered for storage, wherein each instance of data that is entered isallocated a unique identifier such that each instance can be uniquelyreferred to; a relationship definition table, stored in said memory ofsaid computer system, for storing a plurality of relationshipdefinitions, a relationship being defined by exactly three uniqueidentifiers, each relationship definition having three data fields, eachof said exactly three unique identifiers being contained in a respectiveone of said three data fields of said relationship definition; andsearch means, for performing a first search based on an entered searchquery, said search query having three data fields each containing asearch parameter for matching to the contents of the corresponding oneof said three data fields of said relationship definitions stored insaid relationship definition table, said search parameters including aunique identifier or a match-to-all-search parameter which matches tothe corresponding data field in the relationship definition regardlessof the contents of said data field, wherein each of said searchparameters is compared with the contents of the corresponding data fieldof said relationship definitions stored in said relationship definitiontable, and only those relationship definitions in which the contents ofthe three data fields match said three search parameters are retrievedas a set of results.
 36. The system of claim 35 wherein the search meansare configured to perform a second search based on a second searchquery, said second search query also having three data fields eachcontaining a search parameter for matching to the contents of thecorresponding one of said three data fields of said relationshipdefinitions stored in said relationship definition table, said secondsearch being further based on a selected data field in both the firstand second search query, wherein each of said search parameters of saidsecond search query is compared with the contents of the correspondingdata field of said relationship definitions stored in said relationshipdefinition table, and only those relationship definitions in which thecontents of the three data fields match said three search parameters,and in which the unique identifier in the data field specified for thesecond search query is identical to a unique identifier in the datafield specified in respect of the first search query and retrieved inthe first set of results are returned as a second set of results, andwherein the first set of results and the second set of results arecombined to form a third set comprising every pair-wise combination ofrelationship definitions for which the unique identifier of the instanceof data at the position specified for the first search query and theposition specified for the second search query is the same.
 37. Thesystem of claim 36 wherein the data field specified for the first searchquery and the data field specified for the second search query bothcontain a match-to-all search parameter.
 38. The system of claim 35wherein a unique identifier is also allocated to at least onerelationship definition entered into said relationship definition table,such that the at least one relationship definition can be uniquelyreferred to.
 39. The system of claim 38 wherein in a relationshipdefinition, can contain in place of the unique identifier of an instanceof data, the unique identifier of a relationship definition stored insaid relationship definition table, such that the relationshipdefinition represents a relationship between an odd number, greater thanor equal to five, of instances of data stored in said entity instancetable.
 40. The system of claim 35 wherein an instance of data is used torepresent a single nameable entity, or a relationship between entities.41. The system of claim 40 wherein one of the unique identifierscontained in a relationship definition refers to instances of data thatrepresent relationships between entities.
 42. The system of claim 35wherein said entity instance table includes a binary type fieldassociated with each instance of data and each instance of data storedin said entity instance table is stored with an indicator of the binarytype of the data in the corresponding binary type field.
 43. A systemfor storing data, comprising: a computer system having a processor and amemory; and an entity instance table, stored in said memory of saidcomputer system, into which instances of data can be entered forstorage, wherein each instance of data that is entered is allocated aunique identifier such that each instance can be uniquely referred to;said entity instance table being configured to store a plurality ofrelationship definitions, each relationship definition also beingallocated a unique identifier such that each relationship definition canbe uniquely referred to, and each relationship definition having threedata fields, a relationship being defined by exactly three uniqueidentifiers, and each of said exactly three unique identifiers beingcontained in a respective one of said three data fields of saidrelationship definition whereby a relationship definition represents arelationship between any odd number, greater than or equal to three, ofselected instances of data.
 44. The system of claim 43, furthercomprising a comparator for comparing an input instance of data that hasbeen entered for storage with existing instances of data already storedin said entity instance table, and returning the unique identifier of anexisting instance of data stored in said entity instance table, if theinput instance of data is identical with said existing instance of data;and a user-interface for prompting a user to identify whether theexisting instance of data and the input instance of data which isidentical are to be associated with one another, wherein if the userindicates that the existing instance of data is not to be associatedwith the input instance of data, a unique identifier is allocated to theinput instance of data, and the instance of data is stored in the entityinstance table.
 45. The system of claim 43 wherein an instance of datais used to represent a single nameable entity, or a relationship betweenentities.
 46. The system of claim 45 wherein one of the uniqueidentifiers contained in a relationship definition refers to instancesof data that represent relationships between entities.
 47. The system ofclaim 43 wherein said entity instance table includes a binary type fieldassociated with each instance of data and each instance of data storedin said entity instance table is stored with an indicator of the binarytype of the data in the corresponding binary type field.
 48. A systemfor storing and retrieving data, comprising: a computer system having aprocessor and a memory; an entity instance table, stored in said memoryof said computer system, into which instances of data can be entered forstorage, wherein each instance of data that is entered is allocated aunique identifier such that each instance can be uniquely referred to;said entity instance table being configured to store a plurality ofrelationship definitions, each relationship definition also beingallocated a unique identifier such that each relationship definition canbe uniquely referred to, and each relationship definition having threedata fields, a relationship being defined by exactly three uniqueidentifiers, each of said exactly three unique identifiers beingcontained in a respective one of said three data fields of saidrelationship definition wherein a relationship definition represents arelationship between any odd number, greater than or equal to three, ofselected instances of data; and search means, for performing a firstsearch based on an entered search query, said search query having threedata fields each containing a search parameter for matching to thecontents of the corresponding one of said three data fields of saidrelationship definitions stored in said entity instances table, saidsearch parameters including a unique identifier or a match-to-all-searchparameter, which matches to the corresponding data field in therelationship definition regardless of the contents of said data field;wherein each of said search parameters is compared with the contents ofthe corresponding data field of said relationship definitions stored insaid relationship definition table, and only those relationshipdefinitions in which the contents of the three data fields match saidthree search parameters are retrieved as a set of results.
 49. Thesystem of claim 48 wherein the search means are configured to perform asecond search based on a second search query, said second search queryalso having three data fields each containing a search parameter formatching to the contents of the corresponding one of said three datafields of said relationship definitions stored in said entity instancetable, said second search being further based on a selected data fieldin both the first and second search query, wherein each of said searchparameters of said second search query is compared with the contents ofthe corresponding data field of said relationship definitions stored insaid entity instance table, and only those relationship definitions inwhich the contents of the three data fields match said three searchparameters, and in which the unique identifier in the data fieldspecified for the second search query is identical to a uniqueidentifier in the data field specified in respect of the first searchquery and retrieved in the first set of results are returned as a secondset of results, and wherein the first set of results and the second setof results are combined to form a third set comprising the uniqueidentifiers for the two relationship definitions of every pair-wisecombination of relationship definitions for which the unique identifierof the instance of data at the position specified for the first searchquery and the position specified for the second search query is thesame.
 50. The system of claim 49 wherein the data field specified forthe first search query and the data field specified for the secondsearch query both contain a match-to-all search parameter.
 51. Thesystem of claim 48 wherein an instance of data is used to represent asingle nameable entity, or a relationship between entities.
 52. Thesystem of claim 51 wherein one of the unique identifiers contained in arelationship definition refers to instances of data that representrelationships between entities.
 53. The system of claim 48 wherein saidentity instance table includes a binary type field associated with eachinstance of data and each instance of data stored in said entityinstance table is stored with an indicator of the binary type of thedata in the corresponding binary type field.
 54. A computer programproduct comprising a recording medium which is readable by a computerand having program code stored thereon for execution on a computer, saidprogram code defining: an entity instance table into which instances ofdata can be entered for storage, wherein each instance of data that isentered is allocated a unique identifier such that each instance can beuniquely referred to; and a relationship definition table for storing aplurality of relationship definitions, each relationship definitionhaving three data fields, wherein a relationship is defined by exactlythree unique identifiers and each of said exactly three uniqueidentifiers being contained in a respective one of said three datafields of said relationship definition.
 55. The computer program productof claim 54, wherein the program code further defines: a comparator forcomparing an input instance of data that has been entered for storagewith existing instances of data already stored in said entity instancetable, and for returning the unique identifier of an existing instanceof data stored in said entity instance table, if the input instance ofdata is identical with said existing instance of data; and auser-interface for prompting a user to identify whether the existinginstance of data and the input instance of data which is identical areto be associated with one another, wherein if the user indicates thatthe existing instance of data is not to be associated with the inputinstance of data, a unique identifier is allocated to the input instanceof data, and the instance of data is stored in the entity instancetable.
 56. The computer program product of claim 54 wherein a uniqueidentifier is also allocated to at least one relationship definitionentered into said relationship definition table, such that the at leastone relationship definition can be uniquely referred to.
 57. Thecomputer program product of claim 56 wherein in a relationshipdefinition, can contain in place of the unique identifier of an instanceof data, the unique identifier of a relationship definition stored insaid relationship definition table, such that the relationshipdefinition represents a relationship between an odd number, greater thanor equal to five, of instances of data stored in said entity instancetable.
 58. The computer program product of claim 54 wherein an instanceof data is used to represent a single nameable entity, or a relationshipbetween entities.
 59. The computer program product of claim 58 whereinone of the unique identifiers contained in a relationship definitionrefers to instances of data that represent relationships betweenentities.
 60. The system of claim 54 wherein each instance of datastored in said entity instance table is stored with an indicator of thebinary type of the data.
 61. A computer program product having arecording medium which is readable by a computer and recorded thereoncomputer program code for execution on a computer, said computer programcode defining: an entity instance table, into which instances of datacan be entered for storage, wherein each instance of data that isentered is allocated a unique identifier such that each instance can beuniquely referred to; a relationship definition table for storing aplurality of relationship definitions, each relationship definitionhaving three data fields, each data field containing the uniqueidentifier of a selected instance of data stored in said entity instancetable, wherein a relationship is defined by the unique identifiers ofexactly three instances of data and each of said three uniqueidentifiers being contained in a respective one of said three datafields of said relationship definition; and search means, for performinga first search based on an entered search query, said search queryhaving three data fields each containing a search parameter for matchingto the contents of the corresponding one of said three data fields ofsaid relationship definitions stored in said relationship definitiontable, said search parameters including a unique identifier or amatch-to-all-search parameter, which matches to the corresponding datafield in the relationship definition regardless of the contents of saiddata field; wherein each of said search parameters is compared with thecontents of the corresponding data field of said relationshipdefinitions stored in said relationship definition table, and only thoserelationship definitions in which the contents of the three data fieldsmatch said three search parameters are retrieved as a set of results.62. The computer program product of claim 61 wherein the search meansare configured to perform a second search based on a second searchquery, said second search query also having three data fields eachcontaining a search parameter for matching to the contents of thecorresponding one of said three data fields of said relationshipdefinitions stored in said relationship definition table, said secondsearch being further based on a selected data field in both the firstand second search query, wherein each of said search parameters of saidsecond search query is compared with the contents of the correspondingdata field of said relationship definitions stored in said relationshipdefinition table, and only those relationship definitions in which thecontents of the three data fields match said three search parameters,and in which the unique identifier in the data field specified for thesecond search query is identical to a unique identifier in the datafield specified in respect of the first search query and retrieved inthe first set of results are returned as a second set of results, andwherein the first set of results and the second set of results arecombined to form a third set comprising every pair-wise combination ofrelationship definitions for which the unique identifier of the instanceof data at the position specified for the first search query and theposition specified for the second search query is the same.
 63. Thecomputer program product of claim 62 wherein the data field specifiedfor the first search query and the data field specified for the secondsearch query both contain a match-to-all search parameter.
 64. Thecomputer program product of claim 61 wherein a unique identifier is alsoallocated to at least one relationship definition entered into saidrelationship definition table, such that the at least one relationshipdefinition can be uniquely referred to.
 65. The computer program productof claim 64 wherein in a relationship definition, can contain in placeof the unique identifier of an instance of data, the unique identifierof a relationship definition stored in said relationship definitiontable, such that the relationship definition represents a relationshipbetween an odd number, greater than or equal to five, of instances ofdata stored in said entity instance table.
 66. The computer programproduct of claim 61 wherein an instance of data is used to represent asingle nameable entity, or a relationship between entities.
 67. Thecomputer program product of claim 66 wherein one of the uniqueidentifiers contained in a relationship definition refers to instancesof data that represent relationships between entities.
 68. The computerprogram product of claim 67, wherein the program code further defines acomparator for comparing an input instance of data that has been enteredfor storage with existing instances of data already stored in saidentity instance table, and returning the unique identifier of anexisting instance of data stored in said entity instance table, if theinput instance of data is identical with said existing instance of data;and a user-interface for prompting a user to identify whether theexisting instance of data and the input instance of data which isidentical are to be associated with one another, wherein if the userindicates that the existing instance of data is not to be associatedwith the input instance of data, a unique identifier is allocated to theinput instance of data, and the instance of data is stored in the entityinstance table.
 69. The system of claim 61 wherein each instance of datastored in said entity instance table is stored with an indicator of thebinary type of the data.
 70. A computer program product having arecording medium which is readable by a computer having program coderecorded thereon for execution on a computer, said program codedefining: an entity instance table into which instances of data can beentered for storage, wherein each instance of data that is entered isallocated a unique identifier such that each instance can be uniquelyreferred to; said entity instance table being configured to store aplurality of relationship definitions, each relationship definition alsobeing allocated a unique identifier such that each relationshipdefinition can be uniquely referred to, and each relationship definitionhaving three data fields, wherein a relationship is defined by exactlythree unique identifiers, each of said exactly three unique identifiersbeing contained in a respective one of said three data fields of saidrelationship definition and the relationship definition represents arelationship between any odd number, greater than or equal to three, ofselected instances of data.
 71. The computer program product of claim 70wherein an instance of data is used to represent a single nameableentity, or a relationship between entities.
 72. The computer programproduct of claim 71 wherein one of the unique identifiers contained in arelationship definition refers to instances of data that representrelationships between entities.
 73. The system of claim 70 wherein eachinstance of data stored in said entity instance table is stored with anindicator of the binary type of the data.
 74. A computer program productfor storing and retrieving data, having a recording medium readable by acomputer and having program code recorded thereon for execution on acomputer, said program code defining: an entity instance table intowhich instances of data can be entered for storage, wherein eachinstance of data that is entered is allocated a unique identifier suchthat each instance can be uniquely referred to; said entity instancetable being configured to store a plurality of relationship definitions,each relationship definition also being allocated a unique identifiersuch that each relationship definition can be uniquely referred to, andeach relationship definition having three data fields, wherein arelationship is defined by exactly three unique identifiers, each ofsaid three unique identifiers being contained in a respective one ofsaid three data fields of said relationship definition and therelationship definition represents a relationship between any oddnumber, greater than or equal to three, of selected instances of data;and search means, for performing a first search based on an enteredsearch query, said search query having three data fields each containinga search parameter for matching to the contents of the corresponding oneof said three data fields of said relationship definitions stored insaid entity instances table, said search parameters including a uniqueidentifier or a match-to-all-search parameter, which matches to thecorresponding data field in the relationship definition regardless ofthe contents of said data field; wherein each of said search parametersis compared with the contents of the corresponding data field of saidrelationship definitions stored in said relationship definition table,and only those relationship definitions in which the contents of thethree data fields match said three search parameters are retrieved as aset of results.
 75. The computer program product of claim 74 wherein thesearch means are configured to perform a second search based on a secondsearch query, said second search query also having three data fieldseach containing a search parameter for matching to the contents of thecorresponding one of said three data fields of said relationshipdefinitions stored in said entity instance table, said second searchbeing further based on a selected data field in both the first andsecond search query, wherein each of said search parameters of saidsecond search query is compared with the contents of the correspondingdata field of said relationship definitions stored in said entityinstance table, and only those relationship definitions in which thecontents of the three data fields match said three search parameters,and in which the unique identifier in the data field specified for thesecond search query is identical to a unique identifier in the datafield specified in respect of the first search query and retrieved inthe first set of results are returned as a second set of results, andwherein the first set of results and the second set of results arecombined to form a third set comprising the unique identifiers for thetwo relationship definitions of every pair-wise combination ofrelationship definitions for which the unique identifier of the instanceof data at the position specified for the first search query and theposition specified for the second search query is the same.
 76. Thecomputer program product of claim 75 wherein the data field specifiedfor the first search query and the data field specified for the secondsearch query both contain a match-to-all search parameter.
 77. Thecomputer program product of claim 74 wherein an instance of data is usedto represent a single nameable entity, or a relationship betweenentities.
 78. The computer program product of claim 77 wherein one ofthe unique identifiers contained in a relationship definition refers toinstances of data that represent relationships between entities.
 79. Thesystem of claim 74 wherein each instance of data stored in said entityinstance table is stored with an indicator of the binary type of thedata.
 80. A computer program product comprising a recording medium whichis readable by a computer and having program code recorded thereon whichwhen executed on a computer causes the computer to: provide an entityinstance table into which instances of data can be entered, the entityinstance table being stored in a memory of a computer; receive instancesof data and storing the instances in the entity instance table; allocatea unique identifier to each instance of data received for storage in theentity instance table, such that each instance can be uniquely referredto; provide a relationship definition table for storing a plurality ofrelationship definitions, each relationship definition having three datafields, and said relationship definition table being stored in thememory of the computer; and receive three unique identifiers of selectedinstances of data stored in the entity instance table and storing thethree unique identifiers as a relationship definition in therelationship definition table, a relationship being defined by theunique identifiers of exactly three instances of data and each of thethree unique identifiers being contained in a respective one of thethree data fields of the relationship definition.
 81. A computer programproduct comprising a recording medium which is readable by a computerand having program code recorded thereon which when executed on acomputer causes the computer to: provide an entity instance table intowhich instances of data can be entered, the entity instance table beingstored in a memory of a computer; receive instances of data and storingthe instances in the entity instance table; allocate a unique identifierto each instance of data received for storage in said entity instancetable, such that each instance can be uniquely referred to; provide arelationship definition table for storing a plurality of relationshipdefinitions, each relationship definition having three data fields, andsaid relationship definition table being stored in the memory of saidcomputer; receive three unique identifiers of selected instances of datastored in said entity instance table and storing the three uniqueidentifiers as a relationship definition in said relationship definitiontable, a relationship being defined by exactly three unique identifiersand each of the exactly three unique identifiers being contained in arespective one of the three data fields of the relationship definition;receive a search query, having three data fields each containing asearch parameter for matching to the contents of the corresponding oneof the three data fields of the relationship definitions stored in therelationship definition table; compare each of the search parameterswith the contents of the corresponding data field of said relationshipdefinition stored in the relationship definition table; and retrieve, asa set of results, only those relationship definitions in which thecontents of the three data fields match said three search parameters,wherein the search parameter can include a unique identifier or amatch-to-all search parameter, which matches to the corresponding datafield in the relationship definition regardless of the contents of thedata field.
 82. A computer program product comprising a recording mediumwhich is readable by a computer and having program code recorded thereonwhich when executed on a computer causes the computer to: provide anentity instance table into which instances of data can be entered, theentity instance table being stored in a memory of a computer; receiveinstances of data and storing the instances in the entity instancetable; allocate a unique identifier to each instance of data receivedfor storage in the entity instance table, such that each instance can beuniquely referred to; receive three unique identifiers of selectedinstances of data stored in the entity instance table and storing thethree unique identifiers as a relationship definition in the entityinstance table, a relationship being defined by exactly three uniqueidentifiers, the relationship definition having three data fields andeach of the exactly three unique identifiers being contained in arespective one of the three data fields; allocate a unique identifier toa relationship definition received for storage in the entity instancetable, such that the relationship definition can be uniquely referredto; and receive three unique identifiers for storage as a secondrelationship definition, wherein at least one of the unique identifiersis that of a relationship definition already stored in the entityinstance table, the second relationship definition thereby representinga relationship between an odd number, greater than or equal to five, ofinstances of data stored in the entity instance table.
 83. A computerprogram product comprising a recording medium which is readable by acomputer and having program code recorded thereon which when executed ona computer causes the computer to: provide an entity instance table intowhich instances of data can be entered, the entity instance table beingstored in the memory of the computer; receive instances of data andstoring the instances in the entity instance table; allocate a uniqueidentifier to each instance of data received for storage in the entityinstance table, such that each instance can be uniquely referred to;receive the unique identifiers of three instances of data stored in theentity instance table and storing the unique identifiers as arelationship definition in the entity instance table, a relationshipbeing defined by exactly three unique identifiers, the relationshipdefinition having three data fields and each of the exactly three uniqueidentifiers being contained in a respective one of the three datafields; allocating a unique identifier to a relationship definitionreceived for storage in the entity instance table, such that therelationship definition can be uniquely referred to; receiving threeunique identifiers for storage as a second relationship definition,wherein at least one of the unique identifiers is that of a relationshipdefinition already stored in the entity instance table, the secondrelationship definition representing a relationship between an oddnumber, greater than or equal to five, of instances of data stored inthe entity instance table; receive a search query, having three datafields each containing a search parameter for matching to the contentsof the corresponding one of the three data fields of the relationshipdefinitions stored in the entity instance table; compare each of thesearch parameters with the contents of the corresponding data field ofthe relationship definition stored in the entity instance table; andretrieve, as a set of results, only those relationship definitions inwhich the contents of the three data fields match the three searchparameters, wherein said search parameter can include a uniqueidentifier or a match-to-all search parameter which matches to thecorresponding data field in the relationship definition regardless ofthe contents of the data field.